1. Field of the Invention
The present invention relates to the field of providing notification from applications requiring user attention. The present invention also relates to the field of managing a plurality of outstanding attention requests with an Attention Manager.
2. Related Art
As the components required to build a computer system have reduced in size, new categories of computer systems have emerged. One of the new categories of computer systems is the “palmtop” computer system. A palmtop computer system is a computer that is small enough to be held in the hand of a user and can therefore be “palm-sized.” Most palmtop computer systems are used to implement various personal information management (PIM) applications such as an address book, a daily organizer, scheduling calendar, and electronic notepads, to name a few. Palmtop computers with PIM software have been known as Personal Digital Assistants (hereinafter referred to as “PDAs”).
Previously, support for various types of alarms used to get a user's attention were simple and effective for PDAs with less capability. In those cases, the operating system for a PDA would require the application with a record entry requiring user attention to be responsible for the alarm and user experience. However, the alarm system was most effective when operating only with one application with alarm capabilities. This was needed because different applications with alarm capabilities would be unaware of another application's set of alarms.
Typically, this application would be a datebook or calendar application. The calendar application could be used to arrange daily meetings and events. The operating system, through an alarm manager, maintains a queue of times for alarms and associated applications to be sublaunched. Thereafter, the application, e.g., the calendar application, is entirely responsible for the alarm/user experience.
Multiple applications with independent alarm systems did not provide an adequate user experience. In a typical scenario, alarms that are invoked may be “snoozed” or suspended for a predetermined period of time to allow a user to interact with applications on the PDA. This is accomplished by hitting a “snooze” button. The user would later return to and follow up with the snoozed alarm at a more convenient time. In the best case, the snooze button is intended to snooze all outstanding alarms or snoozed alarms.
However, since each application was responsible for user interaction with alarms, snoozing an alarm in one application would only snooze all the outstanding alarms associated with that application. The user would have to tap the snooze button for each application's alarm dialog before being allowed to use the device.
Thus, operating systems only allow one application to invoke an alarm dialog at a time. Accordingly, this one-to-one relationship between an operating system and one application with an alarm system would be inadequate with today's more sophisticated personal digital assistants that have many applications requiring a user's attention.
Another problem with previous alarm systems involve multiple alarms that have been set-off but not cleared. A typical user scenario is one where a user has left the PDA unattended for a period of time, such as when on vacation, and returns to an unknown stack of set-off alarms that must be tediously dismissed on an individual basis.
The scenario starts when the “next” alarm, the first alarm while the user is on vacation, goes off. The operating system through an alarm manager sends a pair of sublaunch codes to the registered or corresponding application associated with the record entry requiring attention. The first sublaunch is user-interface free. The application typically checks to see if the alarm is really still valid (e.g. the meeting has not been canceled). If the alarm is still valid, then the operating system sends the second sublaunch.
The second sublaunch provides for a user interface. Here, the application is allowed to put up a dialog informing the user of the alarm with some rudimentary user interface. For example, a typical calendar application responds to the second sublaunch by putting up an alarm dialog.
The alarm dialog opens a window on the screen, and creates a nested event loop to handle events for the dialog. This nested event loop ignores virtually all events that would cause the dialog to go away, e.g., hard key characters that would cause an application to launch are ignored by this event loop. The result is the dialog is fixed on the screen, and it can not be dismissed until one of the embedded buttons is tapped.
Also, the currently active application remains active ‘behind’ the alarm dialog. However, a user cannot see or interact with the application, because the alarm dialog takes up the full screen. Additionally, the user cannot interact with the active application because the dialog's nested event loop is processing all events. Thus, the active application is effectively suspended until the dialogs have been dismissed or snoozed.
When a second alarm goes off before the first has been dismissed, the operating system still sends the first sublaunch, but defers the second user interface sublaunch until after the sublaunch from the first alarm has been completed. For applications that put up dialogs, this typically means that only one dialog at a time will appear on the screen.
The operating system does not return to the event loop between sublaunches, so when the first application sublaunch finally returns, the second application's first sublaunch will happen immediately, with third and subsequent application first sublaunches happening if necessary in the same order the alarms went off.
Returning from vacation, the user is only aware of the dialog present on the screen and is unaware that a stack of dialogs may exist. The net result for the user is that each alarm dialog in turn must be dismissed before the device can be used. Additionally, the dialogs are presented with the oldest first. This means that all the older dialogs must be dismissed before the most current dialog can be examined.
Furthermore, the previous alarm system did not allow users to directly navigate to a record entry requiring attention. Navigation to record entries was unnecessary in a typical calendar application because the calendar hard button could be pressed once the alarm stack has been dismissed. Pressing the calendar hard button would navigate the user to the calendar display with the current date and time on-screen. Presumably, the most current or most urgent alarms are associated with the current data.
However, if an alarm is set a significant amount ahead of the event in the future, e.g., a 5-day warning on an un-timed birthday reminder, it may be hard to locate the birthday event once the dialogs have been dismissed. A user would have to investigate all the calendar entries up to and including the birthday entry. Even then, there is no guarantee that the user will recognize that birthday entry is associated with the alarm.
Furthermore, adding a “go to” button would be challenging with this simple application-owned dialog approach. The problem is that in order for a dialog to implement the function, it would have to back out of all pending attention requests. That means essentially throwing away any other information that is waiting to be presented to the user.
Similarly, since the dialogs are stacked into nested event loops, if two applications compete for attention, one wins out and starves the other until the user dismisses that dialog. At this point, the second application takes over. A “go to” subroutine would be severely impacted. Instead of navigating to the application and showing the corresponding data, a subsequent dialog with some other attention request would appear.